< Previous Page | Table of Contents| Next Page >
Overview of C&S Meeting Workflow
Meetings can be created as single-instance meetings (Simple meetings) or Repeating meetings. The overall workflow for meetings (see figure 1) is the same:
The Chair creates a meeting in the Chair’s calendar.
Default information is gathered from the calendar profile, including alarm options, notification preferences, busytime preferences, etc.
Other information such as start and end date, time, timezone for the meeting, room (if used), and participants is gathered from the Chair input.
The Chair can choose to save the document as a draft up to this point. If the draft option is chosen, the information is saved but no invitations are sent, and busytime information for the chair is not altered.
Once the Chair decides that the meeting is ready for processing, the Save and Send Invitation button is used to send invitations to the participants (invitees, room, resources), and the meeting is saved into the Chair’s calendar.
Rooms and Resources send replies to the Chair after processing at the Reservation database. In Domino 7 and later, the RnRMgr task is involved at this point also.
Invitees choose to respond in any of a number of ways:Accept
Decline
Tentatively Accept
Delegate
Counter
In all cases, when the invitee takes action, the chair is sent a notification describing the action. This notice document is a part of the C&S workflow and is used to track attendee status, among other actions. The document must stay in the calendar as long as the meeting is there. These documents are tied to the parent document by the $Ref field.
Even after a meeting is accepted, it can be further acted on by the invitee, who can request further information, can decline, or can delegate the meeting.
Any action (from the Chair or participants) can include comments.
The Chair has actions that can be taken after a meeting is created and responses returned, among which are Confirm, Send Notice, View invitee status, and Cancel.
 |
Back to top
Entry Type: Simple Meeting with Invitations
Workflow Discussion – Simple Meeting with Invitations
In this case one document representing the event is created in the Chair's Calendar file with the CalendarDateTime field set to the starting date and time of the event. The document is displayed in the Chair's calendar. Invite Notices are mailed to the invitees, rooms, and resources. Accepted, declined, and countered notices arrive back in the Chair's inbox (see figure 2).
When an invitee accepts the invitation, the notice is altered by adding the CalendarDateTime item for display on the invitee's calendar. An Accept notice is also sent to the Chair's mail file.
When an invitee tentatively accepts an invitation, the notice is altered by addition of the CalendarDateTime item for display on the invitee's calendar. The notice sent to the Chair has information that the invitee has tentatively accepted. The Busy/Free time appears in the invitee's calendar as free time.
When an invitee counters an invitation, the invitation document is altered to show that the invitee has proposed a new time. A counter notice is sent to the Chair's mailbox. The notice does not display in the invitee’s calendar.
When an invitee declines an invitation, a decline notice is mailed to the Chair of the meeting.
When an invitee delegates an invitation, a Delegate notice is sent to the Chair of the meeting. The Chair uses the notice to tie the delegator to the delegee so that the delegee starts receiving updates on the meeting. The delegator also sends a Delegate notice to the delegee advising them of the delegation.
Chair’s Document
Form: _Calendar Entry
Alias: Appointment
Alarm items
BusyTime items
Mail items
Database Control items
Online Meeting items
Unique Meeting items
$CSFlags = value of ‘c’ on repeat parent and ‘i’ and child document
_ViewIcon = Value is always 158 for Chair’s meeting note
AppointmentType = 3 for Meeting
Form = “Appointment”
Repeats = value is “” for non-repeating
Simple Meeting - Notice to Invitees
Form: (Notice)
Alias: Notice
Mail items
Database Control items
Online Meeting items
Unique Meeting items
_ViewIcon = value is always 133 for invitation
AppointmentType = 3 for Meeting
Form = “Notice”
NoticeType = ”I”
Repeats = value is “” for non-repeating
Simple Meeting – Notice to additional invitee
There is no real difference for a non-repeating meeting invitation to a new invitee. This is here for completeness, because an invitation to a new attendee to an existing repeating meeting is different from the original invitees notice. See Simple Meeting - Notice to Invitees. |
Back to top
Entry Type: Accept Notice – Simple Meeting
Back to top
Entry Type: Counter Notice – Simple Meeting
Back to top
Entry Type: Update Notices
Back to top
Entry Type: Delegate – Simple Meeting
Back to top
Entry Type: Tentative Accept – Simple Meeting
In the case of a simple meeting, when an invitee tentatively accepts an invitation, the invitation document itself is modified appropriately (for instance, the CalendarDateTime item is added) for display on the calendar. Also, an Accept notice is sent to the Chair’s mail file.
The Invitee’s document is exactly the same as when a user accepts the invitation (see Accept Notice – Simple Meeting - Invitee’s Document), except that BookFreeTime is set to “1”, and $BusyPriority is set to “2”, so that the time appears as free time.
The Notice sent to the Chair is exactly the same as when a user accepts the invitation (see Accept Notice – Simple Meeting – Notice to Chair), except that NoticeType is set to “P” to indicate that the invitee has tentatively accepted. |
Back to top
Entry Type: Repeating Meeting
Back to top
Repeating Meeting - Notice to Invitees
Back to top
Repeating Meeting Workflow - Invitee Actions
Invitees have several response options available when a repeat meeting invitation is received, or after the meeting is initially accepted. Figure 4 shows the workflow for Invitee Actions – Repeating Meetings. The documents used in this workflow are addressed below.
 |
Back to top
Entry Type: Accept Notice – Repeat Meeting
Invitee accepts an invitation. When an invitee receives a notice in their mail file and accepts the invitation, the notice in their mail file is suitably altered to become the parent document of the repeat meeting. Child documents to this parent are created for display in the Calendar view. An accept notice is sent to the Chair's mail file.
Repeat meeting notices to additional invitees are slightly different from those to original invitees in that the invitation is a document that has the $Ref item set to a non-existent parent repeat document. That parent repeat document is initially created as a ghost note when the invitation is deposited in the invitee’s inbox. When the user takes action on the invitation, an actual parent repeat document is created. The invitation itself is modified into a repeat child document, and an accept notice is then sent to the Chair's mail file.
Invitee’s parent repeat document
Form: _Calendar Entry
Alias: Appointment
In the case of a repeat meeting, when an invitee accepts an invitation, the invitation document is itself modified suitably to be the “parent document” in the invitee’s mail file. A child to this parent repeat document is created for display in the Calendar view. Also, an accept notice is sent to the Chair’s mail file.
Mail items
Database Control items
Repeat UI fields
Online Meeting items
Unique Meeting items
$CSFlags = ‘c’
_ViewIcon = 158
AppointmentType = 3 for Meeting
Form = “Appointment”
NoticeType =”A”
RepeatInstanceDates – These are put on document at acceptance.
Repeats = value is “1” for repeating
Invitee’s child repeat document
Alarm items
BusyTime items
Mail items
Online Meeting items
Database Control items
Unique Meeting items
$CSFlags = ‘i’
_ViewIcon = 158
AppointmentType = 3 for Meeting
Form = “Appointment”
NoticeType =”A”
Repeats = value is “1” for repeating
Accept - Repeat Meeting - Notice to Chair
Form: (Notice)
Alias: Notice
Mail items
Online Meeting items
Database Control items
Meeting items
$CSFlags = “wm”
_ViewIcon = 83 for accept
AppointmentType = 3 for Meeting
Form = “Notice”
NoticeType =”A”
OriginalStartDate – In most cases this is the same as the StartDateTime of the invitation. If the invitee accepts all, then declines partial set, then accepts some or all of that partial set, then this is the selected date from his/her calendar when he/she accepted.
RepeatInstanceDates – In most cases this item is not present on accept. If invitee accepts all, then declines partial set, then accepts some or all of that partial set, then this is the initial repeat date corresponding to the selected date from his/her calendar when he/she accepted.
Repeats = value is “” for non-repeating
RescheduleEndDateTimes – item not present on original accept. See RepeatInstanceDates above.
RescheduleInstanceDates – item not present on original accept. See RepeatInstanceDates above.
RescheduleStartDateTimes – item not present on original accept. See RepeatInstanceDates above.
Accept Notice – Repeat Meeting -- Additional Invitee
In the case of a repeat meeting to an additional invitee, when an invitee accepts an invitation, the invitation is a document that contains a $Ref to a non-existing parent. That parent repeat document is initially created as a ghost note when the invitation is deposited in the invitees’ inbox. When the user takes action on the invitation, an actual parent repeat document is created. The invitation itself is modified into a repeat child document. Also, an accept notice is sent to the Chair’s mail file.
Accept – Repeat Meeting -- Invitee’s parent repeat document-- Additional Invitee
Form: _Calendar Entry
Alias: Appointment
Mail items
Online Meeting items
Database Control items
Unique Meeting items
$CSFlags = ‘c’
_ViewIcon = 158
AppointmentType = 3 for Meeting
ChairDomain – When repeat parent is created, Chair domain is inserted.
Form = “Appointment”
RepeatInstanceDates – These are put on document at acceptance.
Repeats = value is “1” for repeating
StorageRequiredNames – overloaded with meeting StartDates copied from invitation.
Accept – Repeat Meeting -- Invitee’s child repeat document-- Additional Invitee
Alarm items
BusyTime items
Mail items
Online Meeting items
Database Control items
Unique Meeting items
$CSFlags = ‘i’
_ViewIcon = 158
AppointmentType = 3 for Meeting
Form = “Appointment”
NoticeType = ”A”
Repeats = value is “1” for repeating
RescheduleEndDateTimes –- item removed when acceptance is done
RescheduleInstanceDates –- item removed when acceptance is done
RescheduleStartDateTimes –- item removed when acceptance is done
RescheduleWhich
StorageRequiredNames – overloaded with meeting StartDates from invitation
Accept - Repeat Meeting - Notice to Chair -- Additional Invitee
Form: (Notice)
Alias: Notice
Mail items
Online Meeting items
Database Control items
Unique Meeting items
_ViewIcon = 83 for accept
AppointmentType = 3 for Meeting
Form = “Notice”
NoticeType = ”A”
OriginalStartDate In most cases this is the same as the StartDateTime of invitation. If invitee accepts all, then declines partial set, then accepts some or all of that partial set, then this is the selected date from his/her calendar when he/she accepted.
RepeatInstanceDates In most cases this item is not present on accept. If invitee accepts all, then declines partial set, then accepts some or all of that partial set, then this is the initial repeat date corresponding to the selected date from his/her calendar when he/she accepted.
Repeats = value is “” for non-repeating
StartDateTime In most cases this is the same as the StartDateTime of invitation. If invitee accepts all, then declines partial set, then accepts some or all of that partial set, then this is the selected date from his/her calendar when he/she accepted.
StorageRequiredNames – overloaded with meeting StartDates from invitation |
Back to top
Entry Type: Counter Notice – Repeat Meeting
Counter --Repeating -- Invitee’s repeat children documents
Form: _Calendar Entry
Alias: Appointment
In the case of a repeat meeting, an invitee can propose a new time only after the invitation has been accepted. When the invitee counters the invitation, the repeat child documents are modified suitably to reflect that the invitee has proposed a different time. A counter notice is sent to the Chair's mail file.
The counter action might cause a split in the child repeat documents. The counter notice to the Chair has the item "OriginalStartDate" set to the selected day on the calendar when the counter was proposed. The item "$CSFlags" is set to "wm". The CalendarDateTime item is removed from the repeat child document(s), and the meeting does not show in the Calendar (only in the Meetings, All Calendar Entries views).
Alarm items Alarm items are removed from note when user counters.
BusyTime items - $BusyPriority = 2
Mail items This is still the original information from the invitation.
Online Meeting items
Database Control items
Unique Meeting items
$CSFlags = ‘i’
_ViewIcon = 39
AppointmentType = 3 for Meeting
BookFreeTime = 1
Form = “Notice”
NoticeType =”T”
OriginalStartDate – Selected day on calendar when counter was proposed
RepeatInstanceDates – multiple dates corresponding to the dates being countered
Repeats = value is “1” for non-repeating
Counter – Repeat Meeting - Notice to Chair
Form: (Notice)
Alias: Notice
Mail items
Online Meeting items
Database Control items
Unique Meeting items
$CSFlags = ‘wm’
No $CSWISL item on a Counter
_ViewIcon = 39
AppointmentType = 3 for Meeting
ChairDomain – Inconsistent behavior in Notes for this item. Not always present.
Form = “Notice”
NoticeType = ”T”
OriginalStartDate – Selected day on calendar when counter was proposed
RepeatInstanceDates – Single initial meeting date corresponding to OriginalStartDate
Repeats = value is “” for non-repeating
Decline Repeat Meeting – Invitees Documents
Form: (Notice)
Alias: Notice
Invitee Declines an invitation
If the original invitee (or delegee of entire repeat set) declines the entire repeat set, the parent/child repeat documents are not created. The original invitation "NoticeType" is changed to "R" ( for decline). The "_ViewIcon" item is changed to 84, and the "subject" item is changed to have prefix "Declined:". In other cases such as new invitee to an already existing repeat meeting or accept and then decline, the appropriate repeat child documents are modified with these changes. In addition, the "CalendarDateTime" items will be removed from the declined repeat child documents and the meeting will not show in the Calendar (only in the Meetings, All Calendar Entries views).
Decline Notice to Chair – Repeat Meeting
Form: (Notice)
Alias: Notice
The Principal item contains the person’s calendar owner who is doing decline.
Mail items
From – person sending decline.
Principal – owner of calendar doing decline.
Online Meeting items
Database Control items
Unique Meeting items
$CSFlags = ‘wm’
_ViewIcon = 84
AppointmentType = 3 for Meeting
Form = “Notice”
NoticeType = ”R”
OriginalStartDate – In most cases this is the same as the StartDateTime of invitation. If invitee accepts all and then declines partial set, then this is the selected date from his/her calendar when he/she declined.
RepeatInstanceDates – In most cases this item is not present on accept. If invitee accepts all and then declines partial set, then this is the initial repeat date corresponding to the selected date from his/her calendar when he/she declined.
Repeats = value is “” for non repeating
RescheduleEndDateTimes – item not present if original decline of entire repeat set.
RescheduleInstanceDates – item not present if original decline of entire repeat set.
RescheduleStartDateTimes – item not present if original decline of entire repeat set.
StartDateTime – In most cases this is the same as the StartDateTime of invitation. If invitee accepts all and then declines partial set, then this is the selected date from his/her calendar when he/she declined.
StorageRequiredNames – This item will contain a copy of RescheduleInstanceDates, if that item is present; otherwise, it contains its normal information.
Subject – Subject is “Topic” prefixed by “Delegated:”
|
Back to top
Entry Type: Delegate – Repeat Meeting
In the case of a repeat meeting, when an invitee delegates an invitation, the invitation is sent to the delegee, and a “delegated” notice is sent to the Chair. The Chair uses the “delegated” notice to tie the original invitee to the delegee. This allows the delegee to receive future reschedules, updates, and emails sent to participants.
Delegated – Repeat Meeting -- Delegator Documents
Form: (Notice)
Alias: Notice
Invitee Delegates an invitation.
In the case of a repeat meeting, when an invitee delegates an invitation, the invitation is sent to the delegee, and a "delegated" notice is sent to the Chair. The chair uses the delegated notice to tie the original invitee to the delegee. This allows the delegee to receive future reschedules, updates, and emails sent to participants.
If the original invitee or delegee of entire repeat set delegates the entire repeat set, the parent/child repeat documents are not created. On the delegator side, the original invitation's NoticeType item is changed to "D", the _ViewIcon item to “84”, and the Subject item changed to have a prefix of "Delegated:". The items DelegatedToList, Delegator, and Delegee are created.
In other cases such as adding a new invitee to an already existing repeat meeting, or accept then delegate, the appropriate repeat child documents are modified with these changes. In addition, CalendarDateTime items are removed from the delegated repeat child documents. Busy free time info fields are also updated. The $BusyPriority is changed to “2”, and BookFreeTime is set to “1”.
Mail items
From – person sending delegation notice
Principal – owner of calendar from which delegation notice was sent
Repeat UI fields
Online Meeting items
Database Control items
Unique Meeting items
$CSFlags = “i”. Only exist on Child Repeat Document.
$Ref -- Only exist on Child Repeat Document.
$RefOptions -- Only exist on Child Repeat Document.
_ViewIcon = 84
AppointmentType = 3 for Meeting
Form = “Notice”
NoticeType = ”D”
OriginalStartDate – If invitee delegated entire original repeat set, then this is the original StartDateTime value. If invitee accepts all and then delegates partial set, then this is the selected date from his/her calendar when he/she delegated.
PreventCounter This item is passed through from the Chair’s original invitation
RepeatDates – This item is present only when delegator is delegating entire original repeat.
RepeatEndDates – This item is present only when delegator is delegating entire original repeat.
RepeatInstanceDates – This item is only on Child Repeat Documents. On partial delegation, the repeat child has the initial datetimes for the delegated meetings in this item.
StartDateTime – In most cases this is the same as the StartDateTime of invitation. If invitee accepts all and then delegates partial set, then this is the selected date from his/her calendar when he/she delegated.
StorageRequiredNames – can be overloaded with datetimes when this is a partial delegation
Subject – Subject is “Topic” prefixed by “Delegated:”
Delegated – Repeat Meeting -- Notice to Chair
Form: (Notice)
Alias: Notice
Mail items
From – person sending delegation notice
Principal – owner of calendar from which delegation notice was sent
Online Meeting items
Database Control items
Unique Meeting items
$CSFlags = “wm”
_ViewIcon = 84
AppointmentType = 3 for Meeting
ChairDomain – Not always present.
Form = “Notice”
NoticeType = ”D”
OriginalStartDate – In most cases this is the same as the StartDateTime of invitation. If invitee accepts all and then delegates partial set, then this is the selected date from his/her calendar when he/she delegated.
PreventCounter This item is passed through from the Chair’s original invitation
RepeatInstanceDates – In most cases this item is not present on delegation notice to Chair. If invitee accepts all and then delegates partial set, then this is the initial repeat date corresponding to the selected date from his/her calendar when he/she accepted.
RescheduleEndDateTimes – Only present when doing partial delegation.
RescheduleInstanceDates – Only present when doing partial delegation.
RescheduleStartDateTimes – Only present when doing partial delegation.
StartDateTime – In most cases this is the same as the StartDateTime of invitation. If invitee accepts all and then delegates partial set, then this is the selected date from his/her calendar when he/she delegated.
StorageRequiredNames – inconsistent behavior. This is never overloaded here.
Subject – Subject is “Topic” prefixed by “Delegated:”
Delegated – Repeat Meeting -- Notice to Delegee
Form: (Notice)
Alias: Notice
Mail items
From – person sending delegation notice
Principal – owner of calendar from which delegation notice was sent
Repeat UI fields
Online Meeting items
Database Control items
Unique Meeting items
$CSFlags = “wm”
$Ref -- only present on partial delegation notice
$RefOptions -- only present on partial delegation notice
_ViewIcon = 133
AppointmentType = 3 for Meeting
ChairDomain – must be present
Form = “Notice”
NoticeType = ”L”
OriginalStartDate – If invitee delegated entire original repeat set, then this is the original StartDateTime value. If invitee accepts all and then delegates partial set, then this is the selected date from his/her calendar when he/she delegated.
PreventCounter – This item is passed through from Chair’s original invitation.
RepeatDates This item is present only when delegator is delegating entire original repeat.
RepeatEndDates This item is present only when delegator is delegating entire original repeat.
RepeatInstanceDates – In most cases this item is not present on delegation notice to Chair. If invitee accepts all and then delegates partial set, then this is the initial repeat date corresponding to the selected date from his/her calendar when he/she accepted.
RescheduleEndDateTimes – Only present when doing partial delegation.
RescheduleInstanceDates – Only present when doing partial delegation.
RescheduleStartDateTimes – Only present when doing partial delegation.
StartDateTime – In most cases this is the same as the StartDateTime of invitation. If invitee accepts all and then delegates partial set, then this is the selected date from his/her calendar when he/she delegated.
StorageRequiredNames – overloaded with datetimes
Subject – Subject is “Topic” prefixed by “Invitation (Delegated):” |
Back to top
Entry Type: Tentative Accept – Repeat Meeting
Invitee Tentatively Accepts an invitation.
When an invitee tentatively accepts an invitation, the invitation document itself is suitably modified to be the parent document in the invitee's mail file. A child repeat document is created for display in the Calendar view (as described in Repeat Meetings). An Accept notice with item NoticeType set to "P" is sent the Chair's mail file. Busy free time items are set such that the time appears to be free time.
The Invitee’s Document is exactly the same as when the user Accepts the invitation (see Accept Notice – Repeat meeting – Invitee’s Document), except that the BookFreeTime item is set to “1”, and $BusyPriority is set to “2”, so that the time appears as free time.
The Notice sent to the Chair is exactly the same as when the user Accepts the invitation (see Accept Notice – Repeat Meeting – Notice to Chair), except that the NoticeType item is set to “P” to indicate that the invitee has accepted tentatively. |
Back to top
Entry Type: Update Notice – Various Forms
Update Notices.
Any update notices (Reschedules, Cancellations, Confirmations, Updates, etc.) that are sent from a Notes version 6 or later Chair contain the following additional fields:
RescheduleStartDateTimes
RescheduleEndDateTimes
RescheduleInstanceDates
These fields specify which repeat instances (using RescheduleInstanceDates) are affected, and indicate exactly what the start date and times should be (RescheduleStartDateTimes) and what the end date and times should be (RescheduleEndDateTimes), once processed.
Note that these fields are sent for Updates as well as Reschedules, so the presence of such fields doesn't necessarily mean a change in time. Instead, it allows the chair to control what the notice for the invitee(s) calendar looks like once this notice is processed. Each instance of the meeting to be modified is found in the invitee’s calendar by the key pair of RescheduleInstanceDates and ApptUNID and is processed.
Cancellation Notice to Invitees – Repeat Meeting
Chair Cancels a meeting.
A notice is deposited in the invitee's mail box, informing them that the meeting has been cancelled. The invitee must open the cancellation notice in order to remove the meeting from their calendar, if they had accepted it previously, or the invitee must have the new Notes 8 feature "autoprocess cancellations" turned on to process this automatically upon deposit into the mailfile.
Form: (Notice)
Alias: Notice
Mail items
Online Meeting items
Database Control items
Unique Meeting items
_ViewIcon = 81
AppointmentType = 3 for Meeting
Form = “Notice”
NoticeType = ”C”
OriginalStartDate – selected date on Chair’s calendar from which this request was made
RepeatInstanceDates – Initial date corresponding to OriginalStartDate.
Reschedule – Repeat Meeting
Chair Reschedules a meeting.
Upon accepting a counter from an invitee, or upon a decision to change the time or other information of a meeting, the Chair mails notices to all participants. Upon receiving the invitation, all invitees must go through the process of accepting, declining, etc., if not prohibited by the Chair (as with a broadcast or with an all-hands meeting, for example).
Reschedule – Repeat Meeting – Chair’s documents
Form: (Notice)
Alias: Notice
Reschedule – Repeat Meeting -- Notice to Invitees
Form: (Notice)
Alias: Notice
Mail items
Online Meeting items
Database Control items
Unique Meeting items
$CSFlags “wm”
_ViewIcon = 33
AppointmentType = 3 for Meeting
Form = “Notice”
NoticeType = ”U” |
Back to top
Feedback
To provide your feedback about this content, send a message to ndinfo@us.ibm.com with "C&S Schema" in the subject line. All feedback sent to that address will automatically be routed to the authors for review.
< Previous Page | Table of Contents| Next Page > |
|
|